home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0089 / 515.txt < prev    next >
Text File  |  1997-04-16  |  9KB  |  206 lines

  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Sat,  5 May 90       Volume 90 : Issue  515
  4.  
  5. Today's Topics:
  6.                                 break
  7.                         Programming self-help
  8.                         Supercharger problems
  9.                  update on getting GNU Emacs to work
  10.          What is wrong with Terminator's directory?? (2 msgs)
  11. ----------------------------------------------------------------------
  12.  
  13. Date: 5 May 90 02:33:06 GMT
  14. From: rochester!rit!ultb!jdb9608@rutgers.edu  (J.D. Beutel)
  15. Subject: break
  16. Message-ID: <3060@ultb.isc.rit.edu>
  17.  
  18. Does anybody know how break (i.e., ~C) works on the ST?
  19. Is it something in TOS?  (I wouldn't think so since I don't
  20. remember hearing about it, and I know some programs don't break.)
  21. Is it done in each language?  For instance, does _main() in
  22. Sozobon C scan stdin for ~C and _exit() if it sees it?
  23. (I wouldn't think so since then everything would have to
  24. worry about it.)
  25.  
  26. I'm asking because I'm toying with the idea of a vi-type
  27. Korn shell based on RTX.  I like gu:lam but I don't like microEmacs,
  28. and I miss multi-tasking and job control.  So, thinking about
  29. device drivers, SIGSTOP, and the like, I really should understand ~C.
  30. I suppose I could just have the cli slip in an isr to monitor
  31. whatever tty-type input devices, and grap any ~Z that comes along,
  32. but there'll probably be complications if I don't understand
  33. what else is going on.
  34.  
  35. Or, does Dave Beckmyer's (sp?) shell have vi-like command line editing,
  36. and job control?  I haven't seen it, and from what I heard it's a C shell,
  37. but if it does have those other features I'd hate to re-invent the wheel.
  38. I've seen the RTX docs and have the highest respect for RTX's design
  39. (it reminds me of the kernel my OS Lab team did).
  40.  
  41. --
  42. --
  43. J. David Beutel  11011011  jdb9608@cs.rit.edu      "I am, therefore I am."
  44. Looking for co-op Sept..Feb in NN, OS, VR, or AI.
  45.  
  46. ------------------------------
  47.  
  48. Date: 5 May 90 16:18:12 GMT
  49. From: uvaarpa!murdoch!astsun.astro.Virginia.EDU!gl8f@mcnc.org  (Greg Lindahl)
  50. Subject: Programming self-help
  51. Message-ID: <1990May5.161812.440@murdoch.acc.Virginia.EDU>
  52.  
  53. In article <1990May4.163735.9794@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen
  54.  Jacobs) writes:
  55. >Right off the bat: I'm not volunteering to manage this, and it REQUIRES a
  56. >manager, so the idea may be doomed.
  57. >
  58. >There are a lot of questions of the form "How do I get the ST to do job X
  59. >in language Y".  These are well answered with small example programs.
  60.  
  61. Yes, this would be an excellent way to spread documentation about the
  62. ST. How about one example for each BIOS, XBIOS, and GEMDOS call? A few
  63. complete AES/VDI-based programs? Examples that show how to read the
  64. right mouse button, use the VBI queue, work with GDOS.
  65.  
  66. Any volunteers?
  67.  
  68. >What I will offer to do is contribute a few goodies of this type myself.
  69.  
  70. Ditto.
  71.  
  72. "Perhaps I'm commenting a bit cynically, but I think I'm qualified to."
  73.                                               - Dan Bernstein
  74.  
  75. ------------------------------
  76.  
  77. Date: 5 May 90 15:04:01 GMT
  78. From: mcgill-vision!quiche!calvin!depeche@BLOOM-BEACON.MIT.EDU  (Sam Alan EZUST)
  79. Subject: Supercharger problems
  80. Message-ID: <3344@calvin.cs.mcgill.ca>
  81.  
  82. In article <8261@rice-chex.ai.mit.edu> jpexg@rice-chex.ai.mit.edu (John
  83.  Purbrick) writes:
  84.  > In my original posting about the problems with supercharger:
  85.  >>Problems:
  86.  >>
  87.  >>1] Hercules graphics mode is a little screwy.
  88.  >>  I try it on my mono monitor and about one  inch of the screen's image
  89.  >>  is cut off at the right of the screen. If anyone else experiences
  90.  >>  this, send me mail. I am really concerned about this bug.
  91.  >
  92.  >Obviously what they did was just to map the Hercules screen to the ST. Since
  93.  >Herc expects 720x348 pixels, you will lose some at the edge. The fact that
  94.  >you have a strip at the bottom which isn't used at all is probably not much
  95.  >consolation.
  96.  >
  97.  >John Purbrick
  98.  
  99. Yes, I am replying to myself.
  100.  
  101. Sincere apologies - I didn't realize that there is a facility for changing
  102. the portion of the screen which is in view at the given time.
  103. The / key on the numeric keypad lets you view the left edge, right edge,
  104. or the center of the screen (cutting off both sides partially).
  105.  
  106. I stand corrected. It was a two little lines in the manual which i
  107. must have missed the first few times around...
  108.  
  109. --
  110. |S. Alan Ezust                                |  depeche@calvin.cs.mcgill.ca|
  111. |McGill University School of Computer Science |  Montreal, Quebec, Canada   |
  112. |---------------------------------------------------------------------------|
  113. |                     "The mind is a terrible thing...."                    |
  114.  
  115. ------------------------------
  116.  
  117. Date: 5 May 90 17:26:50 GMT
  118. From: zaphod.mps.ohio-state.edu!mips!daver!ditka!rcb@tut.cis.ohio-state.edu
  119.  (Roy Bixler)
  120. Subject: update on getting GNU Emacs to work
  121. Message-ID: <24485@ditka.UUCP>
  122.  
  123. I was finally able to dump GNU Emacs.  I fixed the problem of temacs
  124. reporting "End of file during parsing" reading through the loadup.el file by
  125. commenting out the reference to "load site-load file" and just including the
  126. contents of the site-load file itself.  As far as I know, running 'dumpfix'
  127. went OK and I now have a valid dumped emacs.
  128.  
  129. The question is now: when I run xemacs, it always says that it can't find
  130. the termcap file.  There is a file in the distribution which claims there is
  131. a sample termcap entry for the atari included, but I can't find the sample
  132. anywhere.  Does anyone have a termcap for atari's vt52 emulation?  For now,
  133. I'm going to get all vt52 entries out of the termcap file here, but a
  134. specialized termcap for the atari is probably better.
  135.  
  136. Thanks to Ed Roeder for his help in getting me this far.
  137.  
  138. Roy Bixler
  139.  
  140.  
  141. ------------------------------
  142.  
  143. Date: 5 May 90 15:02:51 GMT
  144. From: swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan!jfbruno@ucsd.edu  (John
  145.  F. Bruno)
  146. Subject: What is wrong with Terminator's directory??
  147. Message-ID: <3204@rodan.acs.syr.edu>
  148.  
  149. In article <9005041337.AA06734@lonex.radc.af.mil> longj@LONEX.RADC.AF.MIL
  150.  (Jeffrey K. Long) writes:
  151.  >I have been unable to get a directory listing of terminator's "New" directory
  152.  >for some time now.  Using FTP I can get a list of all the directories and
  153.  >see that the "new" directory has an updated time-stamp on it, but when I
  154.  >do CD to new and then try to do an "ls", I always get back an "unreadable"
  155.  >message.  This only seems to happen in the new dirctory, all the others work
  156.  >as they always have.  Has anyone else seen this problem?
  157.  
  158. Access to the /atari/new directory has been changed to write-only for
  159. anonymous ftp users. Probably so programs can be checked out before people
  160. start using them, or maybe to stop people from using that directory for
  161. their own purposes, I don't know.
  162.  
  163. ---jb
  164.  
  165. ------------------------------
  166.  
  167. Date: 6 May 90 00:59:08 GMT
  168. From: usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@ucsd.edu  (Howard
  169.  Chu)
  170. Subject: What is wrong with Terminator's directory??
  171. Message-ID: <11915@stag.math.lsa.umich.edu>
  172.  
  173. In article <3204@rodan.acs.syr.edu> jfbruno@rodan.acs.syr.edu (John F. Bruno)
  174.  writes:
  175. >In article <9005041337.AA06734@lonex.radc.af.mil> longj@LONEX.RADC.AF.MIL
  176.  (Jeffrey K. Long) writes:
  177. > >I have been unable to get a directory listing of terminator's "New" directory
  178. > >for some time now.  Using FTP I can get a list of all the directories and
  179. > >see that the "new" directory has an updated time-stamp on it, but when I
  180. > >do CD to new and then try to do an "ls", I always get back an "unreadable"
  181. > >message.  This only seems to happen in the new dirctory, all the others work
  182. > >as they always have.  Has anyone else seen this problem?
  183.  
  184. >Access to the /atari/new directory has been changed to write-only for
  185. >anonymous ftp users. Probably so programs can be checked out before people
  186. >start using them, or maybe to stop people from using that directory for
  187. >their own purposes, I don't know.
  188.  
  189. This is a simple security precaution. By preventing anonymous users from
  190. seeing the filenames in the directory, we reduce the chance that some malicious
  191. screwball will replace a valid program by a virus-infested one (for example)
  192. by uploading a new file with the identical name. There aren't too many good
  193. solutions to managing an archive that's globally writable.
  194.  
  195. Hard to imagine someone deliberately sabotaging an archive site, but ya never
  196. know. At any rate, with the new indexing efforts, files shouldn't stay in new
  197. very long anyway.
  198. --
  199.   -- Howard Chu @ University of Michigan
  200.   ... the glass is always greener on the side ...
  201.  
  202. ------------------------------
  203.  
  204. End of INFO-ATARI16 Digest V90 Issue #515
  205. *****************************************
  206.